…rm, reap the orphaned test-runner container

Three more real bugs found while chasing continued CI flakiness on the
run_id fix, in order of discovery:

1. The SIGKILL test never actually killed `make`. `(cd DIR && ENV=x
   make test >log 2>&1) &` does not tail-call-exec into `make`
   (confirmed with a standalone repro) — the backgrounded subshell
   stays alive as a separate waiting parent, and `make` runs as its
   own child with a different PID. Killing only the subshell's PID
   killed nothing that mattered: `make` ran to full, uninterrupted,
   normal completion every time. The "orphaned" run and the rerun were
   both really running concurrently to completion, racing each other
   for real — which explains the DNS failures and leftover-resource
   symptoms chased across the last several commits. Now finds and
   kills make's actual PID via `pgrep -P`.

2. scripts/test-services.sh's `docker network rm` can transiently fail
   right after `docker rm -f` on its last container — Docker updates a
   network's endpoint list asynchronously, a short lag behind
   container removal — so a single attempt could leave a harmless but
   permanently-uncleaned empty network behind. Added a short retry
   loop (5 attempts, 0.5s apart).

3. Even with make genuinely killed, its foreground `docker run --rm
   ... make _test` container — untracked, unnamed, distinct from the
   tracked service containers — keeps running for real (pip install +
   pytest against now force-removed services) until it fails and
   exits on its own, holding the old network's last reference for as
   long as that takes (well over a minute under this suite's own
   back-to-back docker load, not a bounded race). This is real,
   accurate behavior a genuine crash would also produce; the test
   itself now explicitly reaps whatever's still attached to the old
   network after the rerun, the same way real incident recovery would,
   instead of waiting for it to free itself.

Verified stable across 6 consecutive full runs (19/19 every time,
including the SIGKILL case) plus the project-discover (46/46) and
dependency-install (12/12) suites, all against a real image.

… the final SIGKILL assertion

CI still occasionally failed sigkill/final-teardown-clean after the
previous fixes, this time with live, running containers bearing a
suffix created shortly after the kill (i.e. plausibly the rerun's own
resources) rather than the killed run's. run_make_test's own wait
semantics mean the rerun's `make test` — and therefore its EXIT trap's
`down` call — has already fully completed by the time this assertion
runs, so nothing legitimate should still be attached to any
devrail-test-* resource at this point. Rather than continue chasing
the exact mechanism on a runner this suite can't fully reproduce
locally, replaced the single immediate check with a bounded (20s),
actively-reaping sweep — force-remove whatever's found, retry the
check, same as the script's own final cleanup() trap already does at
the very end of the whole suite, just done here so this one edge case
isn't a false negative for something already unambiguously abandoned.

Verified stable across 11 consecutive full local runs (19/19 each)
against a real image, plus project-discover (46/46) and
dependency-install (12/12) unaffected.